Frontend Content Security Policy Nonce-generering: Sikring af Dynamiske Scripts

I nutidens landskab for webudvikling er det altafgørende at sikre din frontend. Cross-Site Scripting (XSS)-angreb er fortsat en betydelig trussel, og en robust Content Security Policy (CSP) er en afgørende forsvarsmekanisme. Denne artikel giver en omfattende guide til implementering af CSP med nonce-baseret whitelisting af scripts, med fokus på udfordringerne og løsningerne for dynamisk injicerede scripts.

Hvad er Content Security Policy (CSP)?

CSP er en HTTP-response-header, der giver dig mulighed for at kontrollere de ressourcer, som brugeragenten har tilladelse til at indlæse for en given side. Det er i bund og grund en whitelist, der fortæller browseren, hvilke kilder der er troværdige, og hvilke der ikke er. Dette hjælper med at forhindre XSS-angreb ved at begrænse browseren i at udføre ondsindede scripts, der er injiceret af angribere.

CSP-direktiver

CSP-direktiver definerer de tilladte kilder for forskellige typer ressourcer, såsom scripts, styles, billeder, skrifttyper og mere. Nogle almindelige direktiver inkluderer:

• `default-src`: Et fallback-direktiv, der gælder for alle ressourcetyper, hvis specifikke direktiver ikke er defineret.
• `script-src`: Specificerer de tilladte kilder for JavaScript-kode.
• `style-src`: Specificerer de tilladte kilder for CSS-stylesheets.
• `img-src`: Specificerer de tilladte kilder for billeder.
• `connect-src`: Specificerer de tilladte kilder til at foretage netværksanmodninger (f.eks. AJAX, WebSockets).
• `font-src`: Specificerer de tilladte kilder for skrifttyper.
• `object-src`: Specificerer de tilladte kilder for plugins (f.eks. Flash).
• `media-src`: Specificerer de tilladte kilder for lyd og video.
• `frame-src`: Specificerer de tilladte kilder for frames og iframes.
• `base-uri`: Begrænser de URL'er, der kan bruges i et `<base>`-element.
• `form-action`: Begrænser de URL'er, som formularer kan sendes til.

Styrken ved Nonces

Selvom det kan være effektivt at whiteliste specifikke domæner med `script-src` og `style-src`, kan det også være restriktivt og vanskeligt at vedligeholde. En mere fleksibel og sikker tilgang er at bruge nonces. En nonce (number used once) er et kryptografisk tilfældigt tal, der genereres for hver anmodning. Ved at inkludere en unik nonce i din CSP-header og i `<script>`-tagget på dine inline scripts, kan du fortælle browseren, at den kun skal udføre scripts, der har den korrekte nonce-værdi.

Eksempel på CSP-header med Nonce:

Content-Security-Policy: default-src 'self'; script-src 'nonce-{{nonce}}'

Eksempel på inline script-tag med Nonce:

<script nonce="{{nonce}}">console.log('Hello, world!');</script>

Nonce-generering: Kernekonceptet

Processen med at generere og anvende nonces involverer typisk disse trin:

1. Server-side generering: Generer en kryptografisk sikker, tilfældig nonce-værdi på serveren for hver indgående anmodning.
2. Indsættelse i header: Inkluder den genererede nonce i `Content-Security-Policy`-headeren ved at erstatte `{{nonce}}` med den faktiske værdi.
3. Indsættelse i script-tag: Injicer den samme nonce-værdi i `nonce`-attributten på hvert inline `<script>`-tag, som du vil tillade at blive udført.

Udfordringer med Dynamisk Injicerede Scripts

Mens nonces er effektive for statiske inline scripts, udgør dynamisk injicerede scripts en udfordring. Dynamisk injicerede scripts er dem, der tilføjes til DOM'en efter den indledende sideindlæsning, ofte af JavaScript-kode. Blot at sætte CSP-headeren på den indledende anmodning vil ikke dække disse dynamisk tilføjede scripts.

Overvej dette scenarie: ```javascript function injectScript(url) { const script = document.createElement('script'); script.src = url; document.head.appendChild(script); } injectScript('https://example.com/script.js'); ``` Hvis `https://example.com/script.js` ikke eksplicit er whitelisted i din CSP, eller hvis det ikke har den korrekte nonce, vil browseren blokere dens udførelse, selvom den indledende sideindlæsning havde en gyldig CSP med en nonce. Dette skyldes, at browseren kun evaluerer CSP *på det tidspunkt, hvor ressourcen anmodes/udføres*.

Løsninger for Dynamisk Injicerede Scripts

Der er flere tilgange til at håndtere dynamisk injicerede scripts med CSP og nonces:

1. Server-Side Rendering (SSR) eller Pre-rendering

Hvis det er muligt, så flyt logikken for script-injektion til server-side rendering (SSR)-processen eller brug pre-rendering-teknikker. Dette giver dig mulighed for at generere de nødvendige `<script>`-tags med den korrekte nonce, før siden sendes til klienten. Frameworks som Next.js (React), Nuxt.js (Vue) og SvelteKit er fremragende til server-side rendering og kan forenkle denne proces.

Eksempel (Next.js):

```javascript function MyComponent() { const nonce = getCspNonce(); // Function to retrieve the nonce return ( <script nonce={nonce} src="/path/to/script.js"></script> ); } export default MyComponent; ```

2. Programmatisk Nonce-injektion

Dette indebærer at generere noncen på serveren, gøre den tilgængelig for klient-side JavaScript, og derefter programmatisk at sætte `nonce`-attributten på det dynamisk oprettede script-element.

Trin:

1. Eksponér Noncen: Indlejr nonce-værdien i den indledende HTML, enten som en global variabel eller som en data-attribut på et element. Undgå at indlejre den direkte i en streng, da den let kan manipuleres. Overvej at bruge en sikker kodningsmekanisme.
2. Hent Noncen: I din JavaScript-kode, hent nonce-værdien fra, hvor den blev gemt.
3. Sæt Nonce-attributten: Før du tilføjer script-elementet til DOM'en, sæt dens `nonce`-attribut til den hentede værdi.

Eksempel:

Server-side (f.eks. med Jinja2 i Python/Flask):

```html <div id="csp-nonce" data-nonce="{{ nonce }}"></div> ```

Klient-side JavaScript:

```javascript function injectScript(url) { const nonceElement = document.getElementById('csp-nonce'); const nonce = nonceElement ? nonceElement.dataset.nonce : null; if (!nonce) { console.error('CSP nonce not found!'); return; } const script = document.createElement('script'); script.src = url; script.nonce = nonce; document.head.appendChild(script); } injectScript('https://example.com/script.js'); ```

Vigtige overvejelser:

• Sikker opbevaring: Vær forsigtig med, hvordan du eksponerer noncen. Undgå at indlejre den direkte i en JavaScript-streng i HTML-kilden, da dette kan være sårbart. At bruge en data-attribut på et element er generelt en sikrere tilgang.
• Fejlhåndtering: Inkluder fejlhåndtering for elegant at håndtere tilfælde, hvor noncen ikke er tilgængelig (f.eks. på grund af en fejlkonfiguration). Du kan vælge at springe injektionen af scriptet over eller logge en fejlmeddelelse.

3. Brug af 'unsafe-inline' (Frarådes)

Selvom det ikke anbefales for optimal sikkerhed, tillader brugen af `'unsafe-inline'`-direktivet i dine `script-src` og `style-src` CSP-direktiver, at inline scripts og styles kan udføres uden en nonce. Dette omgår effektivt den beskyttelse, som nonces giver, og svækker din CSP betydeligt. Denne tilgang bør kun bruges som en sidste udvej og med ekstrem forsigtighed.

Hvorfor det frarådes:

Ved at tillade alle inline scripts åbner du din applikation for XSS-angreb. En angriber kunne injicere ondsindede scripts på din side, og browseren ville udføre dem, fordi CSP'en tillader alle inline scripts.

4. Script-Hashes

I stedet for nonces kan du bruge script-hashes. Dette indebærer at beregne SHA-256, SHA-384 eller SHA-512-hashen af scriptets indhold og inkludere den i `script-src`-direktivet. Browseren vil kun udføre scripts, hvis hash matcher den specificerede værdi.

Eksempel:

Antaget at indholdet af `script.js` er `console.log('Hello, world!');`, og dens SHA-256-hash er `sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=`, ville CSP-headeren se sådan ud:

Content-Security-Policy: default-src 'self'; script-src 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='

Fordele:

• Præcis kontrol: Tillader kun specifikke scripts med matchende hashes at blive udført.
• Velegnet til statiske scripts: Fungerer godt, når scriptets indhold er kendt på forhånd og ikke ændres ofte.

Ulemper:

• Vedligeholdelsesomkostninger: Hver gang scriptets indhold ændres, skal du genberegne hashen og opdatere CSP-headeren. Dette kan være besværligt for dynamiske scripts eller scripts, der opdateres ofte.
• Svært for dynamiske scripts: At hashe dynamisk script-indhold i farten kan være komplekst og kan introducere performance-omkostninger.

Bedste Praksis for CSP Nonce-generering

• Brug en kryptografisk sikker tilfældig talgenerator: Sørg for, at din nonce-genereringsproces bruger en kryptografisk sikker tilfældig talgenerator for at forhindre angribere i at forudsige nonces.
• Generer en ny nonce for hver anmodning: Genbrug aldrig nonces på tværs af forskellige anmodninger. Hver sideindlæsning skal have en unik nonce-værdi.
• Opbevar og overfør noncen sikkert: Beskyt noncen mod at blive opsnappet eller manipuleret. Brug HTTPS til at kryptere kommunikationen mellem serveren og klienten.
• Valider noncen på serveren: (Hvis relevant) I scenarier, hvor du skal verificere, at en script-udførelse stammer fra din applikation (f.eks. til analyse eller sporing), kan du validere noncen på server-siden, når scriptet sender data tilbage.
• Gennemgå og opdater din CSP regelmæssigt: CSP er ikke en "sæt og glem"-løsning. Gennemgå og opdater regelmæssigt din CSP for at imødegå nye trusler og ændringer i din applikation. Overvej at bruge et CSP-rapporteringsværktøj til at overvåge overtrædelser og identificere potentielle sikkerhedsproblemer.
• Brug et CSP-rapporteringsværktøj: Værktøjer som Report-URI eller Sentry kan hjælpe dig med at overvåge CSP-overtrædelser og identificere potentielle problemer i din CSP-konfiguration. Disse værktøjer giver værdifuld indsigt i, hvilke scripts der blokeres og hvorfor, så du kan finjustere din CSP og forbedre din applikations sikkerhed.
• Start med en Report-Only-politik: Før du håndhæver en CSP, start med en report-only-politik. Dette giver dig mulighed for at overvåge politikkens indvirkning uden faktisk at blokere nogen ressourcer. Du kan derefter gradvist stramme politikken, efterhånden som du får tillid. `Content-Security-Policy-Report-Only`-headeren aktiverer denne tilstand.

Globale Overvejelser for CSP-implementering

Når du implementerer CSP for et globalt publikum, skal du overveje følgende:

• Internationaliserede domænenavne (IDN'er): Sørg for, at dine CSP-politikker håndterer IDN'er korrekt. Browsere kan behandle IDN'er forskelligt, så det er vigtigt at teste din CSP med forskellige IDN'er for at undgå uventet blokering.
• Content Delivery Networks (CDN'er): Hvis du bruger CDN'er til at levere dine scripts og styles, skal du sørge for at inkludere CDN-domænerne i dine `script-src` og `style-src` direktiver. Vær opmærksom på at bruge wildcard-domæner (f.eks. `*.cdn.example.com`), da de kan introducere sikkerhedsrisici.
• Regionale regulativer: Vær opmærksom på eventuelle regionale regulativer, der kan påvirke din CSP-implementering. For eksempel kan nogle lande have specifikke krav til datalokalisering eller privatliv, der kan påvirke dit valg af CDN eller andre tredjepartstjenester.
• Oversættelse og lokalisering: Hvis din applikation understøtter flere sprog, skal du sikre, at dine CSP-politikker er kompatible med alle sprog. Hvis du f.eks. bruger inline scripts til lokalisering, skal du sørge for, at de har den korrekte nonce eller er whitelisted i din CSP.

Eksempelscenarie: En Flersproget E-handels-hjemmeside

Overvej en flersproget e-handels-hjemmeside, der dynamisk injicerer JavaScript-kode til A/B-testning, brugersporing og personalisering.

Udfordringer:

• Dynamisk script-injektion: A/B-testnings-frameworks injicerer ofte scripts dynamisk for at kontrollere eksperimentvariationer.
• Tredjeparts-scripts: Brugersporing og personalisering kan være afhængige af tredjeparts-scripts, der er hostet på forskellige domæner.
• Sprogspecifik logik: Noget sprogspecifik logik kan være implementeret ved hjælp af inline scripts.

Løsning:

1. Implementer nonce-baseret CSP: Brug nonce-baseret CSP som det primære forsvar mod XSS-angreb.
2. Programmatisk nonce-injektion for A/B-testnings-scripts: Brug den programmatiske nonce-injektionsteknik beskrevet ovenfor til at injicere noncen i de dynamisk oprettede A/B-testnings-script-elementer.
3. Whitelisting af specifikke tredjeparts-domæner: Whitelist omhyggeligt domænerne for betroede tredjeparts-scripts i `script-src`-direktivet. Undgå at bruge wildcard-domæner, medmindre det er absolut nødvendigt.
4. Hashing af inline scripts for sprogspecifik logik: Hvis det er muligt, flyt den sprogspecifikke logik til separate JavaScript-filer og brug script-hashes til at whiteliste dem. Hvis inline scripts er uundgåelige, brug script-hashes til at whiteliste dem individuelt.
5. CSP-rapportering: Implementer CSP-rapportering for at overvåge overtrædelser og identificere enhver uventet blokering af scripts.

Konklusion

At sikre dynamisk injicerede scripts med CSP-nonces kræver en omhyggelig og velplanlagt tilgang. Selvom det kan være mere komplekst end blot at whiteliste domæner, giver det en betydelig forbedring af din applikations sikkerhedsposition. Ved at forstå udfordringerne og implementere de løsninger, der er beskrevet i denne artikel, kan du effektivt beskytte din frontend mod XSS-angreb og bygge en mere sikker webapplikation for dine brugere verden over. Husk altid at prioritere bedste praksis for sikkerhed og regelmæssigt gennemgå og opdatere din CSP for at være på forkant med nye trusler.

Ved at følge principperne og teknikkerne beskrevet i denne guide kan du skabe en robust og effektiv CSP, der beskytter din hjemmeside mod XSS-angreb, samtidig med at du stadig kan bruge dynamisk injicerede scripts. Husk at teste din CSP grundigt og overvåge den regelmæssigt for at sikre, at den fungerer som forventet, og at den ikke blokerer legitime ressourcer.